IDM'2014 Case Study

Jean-Michel Bruel, Benoît Combemale (bruel@irit.fr,benoit.combemale@irisa.fr)
version 1.1, 2014-10-26, 2014
First draft

Introduction

This project is an illustration of how Model-Driven Engineering tools and techniques can help in other model-based fields such as scientific activities (Agronomy in our case study).

People involved in this case study

Conventions

Here are some typographical conventions :

  • we denote modelsc a model in the sense of the scientific community
  • we denote modelmde a model in the sense of the [MDE] community

Expectations

  • In terms of modeling capabilities:

    • this is phase 1 of modeling (close to what GVLE does right now)
    • we want to write text and use graphical rendering to communicate

  • In terms of interoperability with other models:

    • DEVS is already a standard?

  • In terms of semantic/execution/simulation:

  • In terms of normative/standard support …​
  • xxx to be completed by Hélène Raynal xxx

Description of the context

In this section we provide some element to understand the kind of modelssc that scientific entities such as INRA manipulate daily.

Available material

Here’s the list of inputs we had:

Screen captures

Note

More can be found (in French) here.
Modeleconceptuelintegre
Figure 1. Les composants principaux

Pour la partie description hiérarchique, on utilise une approche systémique basée sur la connaissance du domaine (exemple on met ensemble les processus qui relèvent du bilan hydrique de la plante) et le niveau d’interaction. La profondeur de décomposition est fonction des attentes du modélisateur et des habitudes. On s’appuie aussi sur les propriétés DEVS (formalisme sous jacent).

Screen captures (contd.)

Exemple de modèles dans l’interface gvle (VLE est le logiciel utilisé dans RECORD) :

gibgjbgc
Figure 2. Modèle dans l’interface GVLE, 1er niveau

Screen captures (contd.)

ejdecgib
Figure 3. Modèle dans l’interface GVLE, 2ème niveau: Boîte 2CV (qui correspond au modèle de culture)

Screen captures (contd.)

fagbhhdf
Figure 4. Modèle dans l’interface GVLE, 3ème niveau: Modèle SOilFull (processus du sol)

Contributions

This section describe the modeling experiments.

THe basic documents (in addition to the one presented before) is the following : documents/ModèleExploitationAgricole.pdf

Approaches

There are several ways to tackle the problem.

We can follow [IDM12] metamodeling process:

idm12
Figure 5. A metamodeling environment construction process

Approach (ctd.)

We can also follow [MDSEP12]:

  1. Modeling domain analysis
  2. Modeling language design
  3. Modeling language validation

Approach (ctd.)

Parler du papier de [Selic07] pour l’approche profil du CEA LIST. CF. cette figure.

DSL

Profile-based approach

What is a profile ?

  • Abstract syntax for a new language

    • Set of stereotypes
    • Set of OCL constraints

What is a profile ?

profile JT

General process

The idea behing this approach is that there will be some benefits in the use of the UML™ standard. Hence the DSL will be based on UML™ by using the profile mechanisms.

profil BS
Figure 6. A profil based approach (taken from [Tatibouet14] and inspired by [Selic07])

As illustrated in this figure, here is the processus we can follow:

General process

Step #1

Starting from the expected DSL (most of the time a modelsc or a graphical représentation) and a description of the domain model (modelmde)

input
Figure 7. Inputs: description of the domain model

General process

Step #2

A domain modelmde is more precisely defined (e.g. a class diagram such as Main concepts of the domain model)

step1
Figure 8. From modelsc to modelmde

Structural metamodel

image001
Figure 9. Main concepts of the domain model

Functional metamodel

image002
Figure 10. Concepts of the domain model linked to activities

General process

Step #3

The concepts (e.g., Farm in Main concepts of the domain model) are mapped to the more suitable UML™ elements (e.g., Class in Mapping concepts with UML metamodel to define a profile)

step2
Figure 11. Mapping domain concepts to UML metamodel

General process

image003
Figure 12. Mapping concepts with UML metamodel to define a profile

General process

Step #4

If the concepts directly match UML™ concepts (or if there is a way to slightly modify them so that they match) then it is possible to define a profile. (see e.g., Mapping concepts with UML metamodel to define a profile)

Step #5

Else another solution (e.g., defining a metamodel from scratch) should be studied.

Working on the concrete syntax

Step #6

It is time then to "customize" the DSML to make it as close as possible as the user domain representation.

dsml
Figure 13. Customizin the DSML

Additional definitions

image004
Figure 14. Improving the profile

Defining the domain model

Note

There are different ways of defining the domain model:

  • the domain expert provides the domain model (e.g., UML™ class diagram)
  • the UML™ expert translate the concepts from the stakeholders into a domain model
  • the UML™ expert and the domain expert build a modelmde as close as possible of the expected DSL and the UML™ expert extract the core concepts in a domain model

Iterative process

The above process is iterative. The constructs are introduced by step. The profile is experimented in a modelsc importing the profile so that the user can validate that the concepts are captured adequatly. This is were the UML™ expert can use tuning possibilities.

Improvements

The next steps consist in:

  • defining a dedicated diagrams
  • providing a wizard for the new language
  • defining a specific property view (File ▸ New …​ Property View Configuration and then right click on the generated property)

  • Working on the concrete syntax:

    • customizing the styles
    • customizing New ▸ Child
    • customizing the Model explorer
    • packaging together the profile, the property view, the palette, etc.

Tip
  • Papyrus provides a DSML Configuration plugin to help on these steps.
  • There is also the possibility of defining a Feature that group together a set of profiles

The profile is defined:

  • in terms of stereotypes (extending metaclasses)
  • adding specific properties to the stereotype (e.g., period in this figure)
  • adding OCL constraints
Note Using ecore, the process consists in startin from scratch, from an empty metamodel. The domain model is then define "by construction". In the UML profile approach we start with an existing (complete) metamodel and the profiling activity consist in restricting it to specific elements. In this approach the assumption is that their is a benefit in having both additional concepts and tooling, notably in terms of extensibility mecanisms and scalability.

Example of work on the concrete syntax

Let us illustrate the need for a specific concrete syntax.

Activity description (UML Activity Diagram)

CornActivity
WheatActivity

Crop Workshops description

CropWS

Functional Domain Model

FarmingDomainModelFunctional

Structural Domain Model

FarmingDomainModelStucture

Functional profile

FarmingProfileFunctional

Structural profile

FarmingProfileStructure

Using the profile: Farm structure

FarmStructure

Using the profile: Papyrus context

ModelingInterface

Customizing the Model Explorer

ModelingInterfaceZoomModelExplorer

Customizing the Palette (structure)

ModelingInterfaceZoomPalette1

Customizing the Palette (activities)

ModelingInterfaceZoomPalette2

Customizing the Palette (property view, structural element)

ModelingInterfaceZoomPropertiesView1

Customizing the Palette (property view activity element)

ModelingInterfaceZoomPropertiesView3

Animation and external tools coupling

moka1

Animation and external tools coupling

moka2

Animation and external tools coupling

moka3

Conclusion

DSML from scratch: the "Wysiwyg approach"

word
  • No constraint on what we type
  • Immediate visualization of the result
  • Possibility to have templates
  • More and mode styles and quality

DSML as UML profiles: the "LaTeX approach"

dsl
  • Constrained language
  • No immediate visualisation of the result
  • Naturally based on templates
  • Richness of libraries and styles
  • Possibilities to see what you get on (almost) real-time
  • Collaborative and user-friendliness improvements

Converging

  • DSML vs profiling: wrong approach
  • DSML or profiling: good question
  • Both Sirius and Papyrus part of Polarsys!
polarsys logo

Thank you for your attention!

width:80%

I also have some for you!

Note
  • Différence entre DSML et profiles UML?
  • Différence entre syntaxe abstraite et concrète?
  • Différence entre sémantique et génération de code?

Frequently Asked Questions

What are the needs in terms of simulations/executions ?

(by Pascal Dayre): we need to explore complex agro-system dynamic. More information with Helene’s presentation http://devlog.cnrs.fr/idm2013 (vidéo, slides)

Why DEVS? And is it the only target language?

(by Pascal Dayre) DEVS n’est pas un langage cible mais un formalisme mathématique qui permet de modéliser les systèmes selon le paradigme événementiel discret. C’est le formalisme englobant qui permet de formaliser les intéractions entre les sous-composants d’un modèle et ceci de manière hiérarchique (sous-modèle de sous-modèle, etc…​). DEVS est implémenté par le langage VLE. Les spous-comosants d’un modèle est lui implémenté avec d’autres approches formalisées ou mathémathique pour des systèmes qui ont un comportement "continu", équations au différence (c’est la démo lors de la visio), d’autres composants pourraient a priori avoir un comportement décrit par un réseau baysien, etc. Par contre, si on se trouve dans un cas discontinu, on retombe dans le formalisme DEVS pour redécouper en sous-comosant continu avec la déclaration des événements entre sous-composants (modèle atomique au sens DEVS). Donc, le langage VLE implémente ce formalisme DEVS en gérant un bus inter-composants. Il offre des passerelles vers d’autres logiciels R, etc…​ et permet de programmer ses propres comportements en langage C++.

Il offre donc un framework: je ne trouve pas dans la doc de description général de ce framework, ni la grammaire du langage. Peut-etre qu’Helene a une info, un contact. Par contre:

Le Langage cible est le langage VLE:

DEVS abbreviating Discrete Event System Specification is a modular and hierarchical formalism for modeling and analyzing general systems that can be discrete event systems which might be described by state transition tables, and continuous state systems which might be described by differential equations, and hybrid continuous state and discrete event systems. DEVS is a timed event system.

DEVS is a high level formalism that has the ability to encapsulate other formalisms. VLE allows you to use several formalisms in DEVS framework:

  • Ordinary Differential Equations: QSS based on quantization and DESS a wrapping of classical numerical schema like Runge-Kunta, by example.
  • Cellular automaton : CellDevs.
  • Difference equation: DifferenceEquation.
  • Petrinet : PetriNet.
  • Discrete and finite state automaton: Moore and Mealy machines, FDDevs and statechart : FSA.
  • Decision making: an extension of execution of activities plan based on conditional, temporal and precedents constraints.

Glossary

MDE

Model Driven Engineering (IDMfr)

References and links

Thanks!

questions

About…​

Document réalisé par Jean-Michel Bruel, Benoît Combemale (bruel@irit.fr,benoit.combemale@irisa.fr) via Asciidoctor (version 1.5.1) de 'Dan Allen', lui même basé sur AsciiDoc. Pour l’instant ce document est libre d’utilisation et géré par la 'Licence Creative Commons'. Licence Creative Commons licence Creative Commons Paternité - Partage à l'Identique 3.0 non transposé.

/